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Abstract 

In  conventional  database  systems,  performance  is  pri¬ 
marily  measured  by  the  number  of  transactions  com¬ 
pleted  within  a  unit  time.  In  real-time  applications, 
timing  and  criticality  characteristics  of  transactions 
must  be  taken  into  account.  In  this  paper,  we  examine 
the  performance  of  StarBase,  a  firm  real-time  database 
system.  The  deadline  guarantee  ratio  and  average 
response  times  are  the  primary  performance  measures. 
There  have  been  performance  studies  on  real-time  data¬ 
base  systems,  but  most  of  them  were  performed  using 
simulation.  This  work  demonstrates  the  feasibility  of 
developing  a  real-time  database  system  with  an  accept¬ 
able  performance. 

1.  Introduction 

As  real-time  applications  increase  in  complexity,  so  do 
their  data  requirements.  For  several  years,  researchers 
have  sought  a  general  solution  to  the  problem  of  collect¬ 
ing,  storing,  and  retrieving  data  in  real-time  by  devising 
database  management  systems  to  manage  data  in  a  time- 
cognizant  and  predictable  manner  [Yu94],  Despite  all  of 
its  features,  a  conventional  database  system  is  not  quite 
capable  of  meeting  the  demands  of  a  real-time  system. 
Typically,  its  goals  are  to  maximize  transaction  through¬ 
put,  minimize  response  time,  and  provide  some  degree 
of  fairness.  A  real-time  database  system,  however,  must 
adopt  goals  which  are  consistent  with  any  real-time  sys¬ 
tem:  providing  the  best  service  to  the  most  critical  trans¬ 
actions  and  ensuring  some  degree  of  predictability  in 
transaction  processing  [Son94]. 

In  conventional  database  systems,  all  transactions 
should  have  the  same  opportunity  to  obtain  system 
resources  to  help  complete  their  execution.  Since  the 
number,  not  type  of  transactions  completed  in  a  given 
time  unit  is  important,  measuring  throughput  and  aver¬ 
age  response  time  is  an  accurate  way  of  accessing  the 
performance  of  a  conventional  database  system.  In  a 
real-time  database  system,  timing  and  criticality  charac¬ 
teristics  of  transactions  must  be  taken  into  account,  and 
hence  a  different  performance  measure  should  be  used. 
Transactions  with  higher  timing  or  criticality  constraints 


are  of  greater  importance  to  the  database  system  and 
thus,  should  be  allocated  a  larger  share  of  the  available 
computation  time  and  resources.  Given  these  con¬ 
straints,  the  deadline  guarantee  ratio  is  a  much  more 
accurate  measure  of  performance  for  real-time  database 
systems.  To  differentiate  the  importance  of  individual 
transactions,  real-time  transactions  are  assigned  a  prior¬ 
ity  or  criticality  when  submitted.  The  real-time  database 
attempts  to  maximize  the  total  value  for  a  set  of  transac¬ 
tions  by  allocating  system  resources  to  transactions  with 
the  highest  priority  to  provide  the  best  chance  of  com¬ 
pletion  before  their  deadline  expires. 

In  this  paper,  we  examine  the  performance  of  a  firm 
real-time  database  system,  called  StarBase,  being  devel¬ 
oped  at  the  University  of  Virginia.  One  of  our  goal  is  to 
demonstrate  the  feasibility  of  developing  a  real-time 
database  system  with  an  acceptable  performance. 

2.  StarBase 

StarBase  is  a  firm  real-time  database  system  which  sup¬ 
ports  the  concurrent  execution  of  transactions  and  seeks 
to  minimize  the  number  of  high-priority  transactions 
that  miss  their  deadlines  [Leh95J.  StarBase  uses  no  a 
priori  information  about  the  transaction  workload  and 
discards  tardy  transactions  at  their  deadline  points.  Star- 
Base  runs  on  top  of  RT-Mach,  a  real-time  operating  sys¬ 
tem  under  development  at  Carnegie  Mellon  University 
[Tok90] . 

In  a  firm  real-time  setting,  if  a  transaction  cannot  be 
completed  by  the  database  system  within  the  given 
deadline  time,  then  that  transaction  is  discarded  from  the 
system.  This  is  in  contrast  to  a  hard  real-time  database 
system,  where  a  transaction  missing  a  deadline  can 
result  in  a  catastrophic  event,  and  a  soft  real-time  data¬ 
base  system,  where  there  is  still  some  value  associated 
with  completing  a  transaction  even  after  its  deadline  has 
passed. 

StarBase  differs  from  previous  real-time  database  work 
in  that  a)  it  relies  on  a  real-time  operating  system  which 
provides  priority-based  scheduling  and  time-based  syn¬ 
chronization,  and  b)  it  deals  explicitly  with  data  conten¬ 
tion  and  deadline  handling  in  addition  to  transaction 
scheduling,  the  traditional  focus  of  simulation  studies. 
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Fig.  1:  StarBase  Server  Architecture 

The  design  of  StarBase  is  shown  in  Fig.  1. 

The  StarBase  database  system  receives  transaction 
requests  from  database  clients  and  places  them  on  a  pri¬ 
ority  queue.  It  is  assumed  that  database  clients  are  phys¬ 
ically  disparate  from  the  server,  so  they  pass  messages 
to  communicate  with  the  DBMS  server.  Transaction 
requests  are  sent  via  RT-Mach’s  Inter-Process  Commu¬ 
nication  (IPC)  mechanism  and  are  queued  at  the  server’s 
service  port.  RT-Mach  provides  a  naming  service  with 
which  StarBase  registers  its  service  port  during  initial¬ 
ization.  Clients  look  up  the  service  port  by  querying  the 
name  server  with  StarBase’s  well-known  name.  There 
are  a  fixed  number  of  threads  (light-weight  processes), 
called  Transaction  Managers,  which  dequeue  those 
requests  and  perform  the  basic  operations  which  consti¬ 
tute  the  transaction.  The  transaction  processing  unit  in 
turn  implements  these  basic  operations.  The  transaction 
managers  rely  on  lower-level  services  to  obtain  the 
resources  (memory,  relations,  etc.)  necessary  for  the 
transaction.  Each  resource  manager  must  ensure  that 
transactions  access  their  resources  in  a  consistent  and 
orderly  fashion. 

When  the  transaction  manager  starts  to  service  a  new 
transaction  request,  a  deadline  thread  also  begins  its 
execution.  If  the  deadline  time  expires  at  any  point 
before  the  completion  of  the  transaction  manager,  then 
the  deadline  thread  informs  the  transaction  manager  of 
the  expired  deadline  situation.  The  transaction  manager 


then  terminates  its  execution  and  returns  a  deadline 
abort  message  to  the  client.  Otherwise,  the  transaction 
manager  informs  the  client  with  either  a  simple  “suc¬ 
cess”  response  message  or  possibly  retrieved  results, 
depending  on  the  transaction  request  submitted.  During 
this  time  however,  the  client  is  blocked  waiting  for  a 
message  from  the  server.  This  limitation  prevents  the 
same  client  from  submitting  multiple  transaction 
requests  while  a  former  request  is  still  pending. 

To  resolve  data  conflicts  between  competing  transac¬ 
tions,  a  concurrency  control  algorithm  must  be  used. 
There  are  two  major  types  of  concurrency  control  which 
have  been  considered  for  use  in  real-time  databases: 
lock-based  and  optimistic  methods.  In  general,  lock- 
based  methods  delay  transactions  to  avoid  having  them 
access  data  in  an  inconsistent  way,  whereas  optimistic 
methods  abort  transactions. 

StarBase  uses  a  real-time  optimistic  concurrency  control 
method  called  WAIT-X  [Har91],  which  has  been  experi¬ 
mentally  shown  to  outperform  lock-based  concurrency 
control  methods  in  a  firm  real-time  setting.  With  WAIT- 
X,  a  transaction  T  executes  unhindered  until  it  reaches 
the  point  where  it  can  commit  (i.e.,  make  its  changes  to 
the  data  permanent)  and  WAIT-X  determines  which 
transactions  should  be  aborted  due  to  the  conflict  with  T. 
Unlike  conventional  concurrency  control,  WAIT-X 
employs  a  priority-cognizant  commit  test:  If  high-prior¬ 
ity  transactions  comprise  less  than  X%  of  all  of  T’s  con- 
flictors,  T  can  commit,  aborting  all  conflictors  in  the 
process.  Otherwise  T  waits  so  that  higher  priority  trans¬ 
actions  may  proceed.  It  was  found  experimentally  that 
low  values  of  X  tend  to  minimize  the  deadline  miss  ratio 
for  light  loads,  and  high  values  of  X  tend  to  minimize 
the  deadline  miss  ratio  for  heavy  loads.  When  X  =  50% 
is  used  as  the  threshold  value,  it  minimizes  the  overall 
deadline  miss  ratio,  but  applications  which  require  mini¬ 
mization  of  the  highest-priority  deadline  miss  ratio  must 
use  a  greater  value  for  X. 

StarBase  uses  T-Tree  indexing  to  decrease  the  data  con¬ 
flict  rate  and  improve  response  time.  T-tree  indexing 
was  proposed  specifically  for  in-memory  retrieval  to 
improve  the  performance  over  indexing  mechanisms  for 
disk-based  data  [Leh86].  The  T-tree  is  a  binary  tree 
which  contains  multiple  elements  in  each  node.  The 
description  and  implementation  of  the  T-Tree  indexing 
mechanism  in  StarBase  is  described  in  [Geo93], 

3.  Real-Time  Mach 

StarBase  currently  runs  on  a  486  DX2/50E  machine 
running  the  RT-Mach  MK83i  operating  system.  RT- 
Mach,  a  variant  of  Mach,  provides  many  of  the  priority- 
based  real-time  features  that  StarBase  relies  on  to  ser- 
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vice  transactions  in  a  real-time  environment.  The  RT- 
Mach  features  StarBase  employs  are  briefly  described  in 
this  section. 

3.1.  Real-Time  Threads 

All  real-time  threads  in  StarBase  are  created  as  aperi¬ 
odic  threads.  Given  a  real-time  application  however,  we 
expect  that  some  of  the  transaction  requests  will  arrive 
periodically,  so  it  is  a  good  feature  that  RT-Mach  pro¬ 
vides  both  types  of  threads  [Tok90].  The  priority  field  in 
the  thread  structure  is  used  by  RT-Mach  for  scheduling, 
priority  handoff  and  priority  inheritance  in  RT-EPC,  and 
in  RT-Sync. 

3.2.  Real-Time  IPC  (RT-IPC) 

The  manner  in  which  the  IPC  mechanism  in  RT-Mach 
handles  messages  for  StarBase  can  be  described  by 
three  main  attributes:  the  message  queueing  policy,  the 
priority  hand-off  policy,  and  the  priority  inheritance  pol¬ 
icy.  For  StarBase,  the  queueing  policy  chosen  is  prior¬ 
ity-based,  so  that  the  highest  priority  transaction  is 
always  serviced  by  the  next  available  transaction  man¬ 
ager.  Since  this  message  ordering  does  not  take  the 
deadline  into  account,  transactions  with  the  same  prior¬ 
ity  are  queued  depending  on  their  order  of  arrival. 

The  priority  handoff  is  enabled  in  StarBase,  allowing 
the  transaction  manager  thread  that  reads  the  transaction 
request  message  to  execute  at  the  priority  specified  in 
the  request  message.  This  priority  message  inheritance 
mechanism  lasts  until  the  transaction  manager  thread 
has  finished  servicing  the  transaction  request.  If  a  higher 
priority  thread  receives  a  message  with  a  lower  priority, 
then  no  inheritance  occurs  and  the  thread  continues  to 
execute  at  the  same  priority.  To  prevent  such  a  situation 
from  occurring  in  StarBase,  the  transaction  managers 
are  initialized  with  the  lowest  system  priority  level  pos¬ 
sible.  The  inheritance  mechanism  will  always  then  cor¬ 
rectly  raise  the  priority  level  of  the  transaction  manager 
to  reflect  the  importance  of  the  transaction  request 
[Kit93]. 

3.3.  Real-Time  Synchronization  (RT-Sync) 

Currently,  StarBase  relies  on  the  mutual  exclusion  with 
a  lock  variable  supplied  by  RT-Mach  to  provide  syn¬ 
chronization  between  transactions  during  the  read,  vali¬ 
dation,  and  write  phase  of  the  WAIT-50  scheme.  To 
ensure  that  the  next  highest  priority  transaction  obtains 
the  lock  object  after  it  is  released  by  the  current  transac¬ 
tion,  the  lock  policy  follows  the  basic  priority  inherit¬ 
ance  protocol.  This  policy  prevents  any  possible  chain 


of  blocking  from  middle  priority  transactions  and  guar¬ 
antees  that  the  lower  priority  transaction  is  serviced 
quickly  so  that  the  lock  can  be  released  [Tok91]. 

3.4.  Real-Time  Scheduling 

RT-Mach  supports  many  different  scheduling  policies, 
but  all  RT-Mach  scheduling  policies  other  than  the 
Mach  timesharing  policy  causes  the  MK83i  version  of 
the  RT-Mach  operating  system  to  halt  after  executing 
StarBase  for  a  short  time.  As  a  result,  the  priorities  of 
the  transaction  manager  threads  in  StarBase  are  not 
taken  into  account  by  the  Mach  scheduler,  and  threads 
receive  equal  time  quantums  during  execution  of  trans¬ 
action  requests.  Ideally,  StarBase  should  incorporate  the 
fixed-priority  round  robin  scheduling  policy,  which  allo¬ 
cates  a  higher  time  quantum  of  execution  for  threads 
with  higher  priorities  [Tok90] . 

4.  StarBase  Transaction  Workload  Generator 

The  workload  generator  is  modelled  after  previous  work 
on  two-phase  locking  (2PL)  and  optimistic  concurrency 
control  (OCC)  [Lee95,  Hua91].  In  each  of  these  studies, 
the  workload  generator  provides  adjustable  runtime 
parameters  to  alter  the  workload  submitted  to  the  data¬ 
base  system.  This  section  describes  how  the  StarBase 
transaction  workload  generator  creates  different  work¬ 
load  and  environments  to  test  the  performance  of  Star- 
Base. 

4.1.  Test  Environment 

The  workload  created  by  the  StarBase  workload  genera¬ 
tor  can  simulate  incoming  transactions  for  two  different 
types  of  real-time  application  areas.  The  first  area  is 
information  management  systems,  where  transactions 
arrive  aperiodically  and  consecutive  transactions  have  a 
certain  arrival  period  between  each  other.  In  such  a  sys¬ 
tem,  the  number  of  users  is  fixed,  and  each  user  submits 
a  new  transaction  only  after  the  previous  one  has  com¬ 
pleted.  These  transactions  may  or  may  not  have  timing 
constraints,  and  therefore  have  soft  deadlines.  An  airline 
reservation  system  is  a  good  example  of  this  application 
area  [Hua91j. 

The  other  application  area  is  the  real-time  process  con¬ 
trol  systems.  Unlike  transactions  in  information  man¬ 
agement  systems,  these  transactions  have  hard  timing 
constraints  that  must  be  met  to  prevent  a  catastrophic 
event  from  occurring.  Transactions  in  such  a  system 
arrive  periodically  and  with  hard  real-time  constraints. 
Network  management,  traffic  control,  and  nuclear 
power  plants  all  fall  in  this  application  area  [Kim95], 
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Since  StarBase  is  a  firm  real-time  database,  it  is  reason¬ 
able  to  ask  why  a  hard  real-time  and  soft  real-time  envi¬ 
ronment  is  being  used  to  test  performance.  This  is  the 
first  time  StarBase  has  undergone  any  rigorous  perfor¬ 
mance  testing.  To  accurately  determine  how  StarBase 
performs,  it  was  decided  to  examine  StarBase  under 
both  real-time  environments.  The  results  from  perfor¬ 
mance  testing  would  be  applied  to  the  fixture  develop¬ 
ment  of  StarBase  in  possibly  one  of  these  two 
application  areas,  or  for  the  area  in  which  different  types 
of  transactions  (soft,  firm,  and  hard)  are  all  mixed. 

4.2.  Workload  Transactions 

Transactions  in  a  workload  consist  of  either  read  (select) 
or  read/write  (update)  operations.  The  number  of  select 
and  update  operations  in  a  workload  is  modified  using 
the  probability  of  write  parameter  Pw.  As  this  probabil¬ 
ity  increases,  the  possibilities  of  data  conflicts  between 
transactions  increases  as  well.  The  length  of  a  transac¬ 
tion  is  determined  using  the  tuples  accessed  parameter. 
The  tuples  accessed  by  a  transaction  can  be  an  explicit 
number  or  an  interval  range,  where  the  number  of  tuples 
is  randomly  chosen  from  the  given  range  of  numbers. 

Each  of  the  transactions  in  a  workload  performs  an 
operation  on  relational  tables.These  tables  must  be 
defined  in  advance  so  that  their  schema  information  can 
be  used  in  the  creation  of  transactions  in  the  workload. 
The  sole  requirement  for  tables  used  in  the  transaction 
generation  for  a  workload  is  a  primary  key  attribute  field 
of  float  type.  The  primary  key  serves  as  both  a  possible 
attribute  field  for  indexing  and  also  as  a  way  for  transac¬ 
tions  to  access  different  tuples  within  a  relational  table. 

4.3.  Transaction  Deadline  Calculation 

As  the  transaction  generator  creates  new  transactions,  a 
deadline  function  calculates  an  estimated  deadline  exe¬ 
cution  time  for  the  transaction.  This  deadline  time  for 
the  transaction  is  dependent  on  the  type  of  database 
operation,  the  tuples  accessed,  and  memory  copies  of 
results  to  the  message  buffer  or  to  temporary  storage.  At 
the  present  time,  the  deadline  function  accurately  calcu¬ 
lates  deadline  times  for  select  and  update  operations  that 
access  relational  tables  given  the  following  constraints: 

•  All  attributes  besides  the  primary  key  are  charac¬ 
ter  data  types  and  of  equal  length 

•  A  relation  table  has  no  more  than  1000  tuples 

•  The  total  bytes  of  all  the  attribute  fields  in  the  rela¬ 
tion  is  no  more  than  800  bytes 

•  All  select  and  update  operations  have  a  where 
clause  of  the  form 


“where  primary_key  >=  a  &  primary Jcey  <  b” 
where  a  and  b  are  constants  and  a  <  b 

The  calculated  deadline  time  is  not  total  execution  time, 
but  rather  the  average  expected  time  to  complete  a  trans¬ 
action  assuming  no  other  transactions  are  executing  in 
the  system.  This  time  also  does  not  include  the  required 
message  passing  time  for  sending  the  transaction  mes¬ 
sage  and  receiving  any  results. 

The  timing  results  for  select  operations  on  200  to  1000 
tuple  relation  tables  with  different  total  attribute  bytes 
show  that  the  select  deadline  time,  SDT,  can  be  calcu¬ 
lated  using  the  following  equation: 

SDT  =  SIT  +  (( TTA/200 )  *  Tr) 

SIT  =  Select  Initialization  Time 

Tr  =  Total  time  to  read  200  tuples  from  a  table 

TTA  =  Total  tuples  accessed 

For  tables  with  total  tuples  ranging  from  0  to  1000 
tuples,  there  is  a  direct  relation  between  time  and  tuples 
read.  Tables  with  400  tuples  have  a  Tr  twice  as  large  as 
the  200  tuple  base  case,  tables  with  800  tuples  have  a  Tr 
four  times  as  large,  and  so  on.  Tr  increases  as  the  total 
attributes  bytes  for  a  tuple  goes  up.  This  increase  is  also 
linear  and  can  be  calculated  from  extrapolation  of  the  Tr 
values  for  the  200  and  1000  tuple  relation  tables. 

The  update  deadline  time,  UDT,  is  similar  to  the  SDT 
equation  with  one  exception.  Whereas  the  number  of 
attributes  in  a  relation  does  not  affect  the  select  opera¬ 
tion,  the  update  operation  must  take  this  into  account.  A 
table  that  has  400  tuples  with  1  attribute  field  will  have 
different  update  times  than  a  table  that  has  200  tuples 
with  2  attribute  fields.  Each  extra  attribute  adds  a  con¬ 
stant  time  that  is  included  in  the  modification  of  the 
SDT  equation  show  below: 

UDT  =  UIT  +  ((TTA/200)  *  Tu ) 

Tu  =  Tbu  +  (( TA  - 1)*  Tx) 

UIT  =  Update  Initialization  Time 

Tu  =  Total  time  to  update  200  tuples  from  a  table 

TTA  =  Total  tuples  accessed 

Tbu  =  Base  update  time  for  200  tuples  from  a  table 

TA  =  Total  attributes  updated 

Tx  =  Extra  Time  for  additional  attribute 

Timing  results  for  update  operations  on  200  to  1000 
tuple  relation  tables  with  different  total  attribute  bytes 
confirm  the  formula  above.  In  Figure  2,  the  increase  in 
update  times  due  to  the  increase  in  the  number  of 
attributes  is  shown. 
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4.4.  Transaction  Priority  Calculation 

Longer  length  transactions  are  more  likely  to  miss  their 
deadlines  due  to  the  increased  probability  of  data  con¬ 
flicts  as  they  access  more  tuples  in  the  relation.  To  avoid 
the  starvation  problem  mentioned  in  [Hua91],  priorities 
are  assigned  according  to  the  number  of  tuples  each 
transaction  accesses.  Given  that  thread  priorities  are 
considered  in  IPC,  synchronization,  and  scheduling  in 
RT-Mach,  longer  transactions  with  higher  priorities  have 
a  better  chance  to  complete.  The  following  equation  is 
used  to  calculate  the  priority  for  a  given  transaction: 

p  =  min _ priority  -  (JTA/TT)  *  (PR) 

min_priority  =  31 
max_priority  =  0 

PR  =  priority  range  =  (min_priority  -  max_priority) . 

TTA  =  total  tuples  accessed 

TT  =  total  tuples  in  the  relation  table 

4.5.  Transactions  in  Information  Systems 

Eight  StarBase  clients  are  initially  created  when  the 
StarBase  workload  generator  is  executed.  The  number 
of  clients  that  are  actually  used  is  a  parameter  that  can 
be  changed.  Once  a  transaction  workload  is  executed  in 
this  environment,  the  client  attempts  to  service  the  next 
transaction  request  stored  in  the  workload.  A  client, 
upon  successfully  obtaining  one  of  the  transaction 
requests  from  the  workload,  sends  the  request  to  the 
StarBase  server,  waits  for  the  server  to  reply,  and  repeats 
this  process  until  all  transactions  in  the  workload  have 
been  serviced. 

4.6.  Transactions  in  Process  Control  Systems 

To  simulate  periodic  transactions,  the  StarBase  work¬ 
load  generator  employs  periodic  threads.  Each  thread 
has  a  client  session  through  which  it  can  immediately 
submit  a  transaction  request.  After  each  thread  period, 
the  next  instantiation  of  the  thread  submits  the  next 
transaction  request  in  the  workload  regardless  of 
whether  the  current  thread  instantiation  has  completed. 
The  StarBase  workload  generator  currently  permits  a 
maximum  of  8  periodic  threads  to  be  created  in  this  test 
environment. 

4.7.  Adjustable  Run-Time  Parameters 

The  parameters  used  strictly  for  the  simulation  of  infor¬ 
mation  systems  are  the  multiprogramming  level  and 


external  think  time.  With  the  multiprogramming  level 
parameter,  the  total  number  of  clients  that  can  send  a 
transaction  request  to  the  StarBase  server  at  any  time  is 
limited  to  the  MPL  level.  This  parameter  allows  us  to 
simulate  an  environment  with  a  fixed  number  of  users. 
The  external  think  time,  on  the  other  hand,  models  the 
elapsed  time  between  submission  of  consecutive  trans¬ 
action  requests  by  the  same  user. 

The  period  window  factor  parameter  is  only  relevant  to 
the  simulation  of  open  process  systems.  In  the  open  pro¬ 
cess  system  environment,  the  same  transactions  arrive 
periodically,  so  we  are  more  interested  in  how  the  data¬ 
base  performs  given  a  particular  transaction  arrival  rate. 
The  period  window  factor  for  the  workload  generator 
controls  this  rate.  After  every  period  window  interval,  a 
new  transaction  in  the  workload  is  sent  to  the  StarBase 
server.  Table  1  lists  the  parameters  used  to  create  spe¬ 
cific  transaction  workloads. 


Table  1:  Workload  Transaction  Parameters 


Parameter 

Settings 

Multiprogramming  Level  (MPL) 

1-12 

Write  Probability  (Pw) 

p 

r— 1 

1 

o 

d 

Tuples  Accessed 

1-  Max 

Deadline  Window  Factor  (a) 

>0.0 

Period  Window  Interval 

>0.0 

Priority 

0-31 

External  Think  Time 

>=0 

5.  Experimental  Results 

5.1.  Experiment  1:  Resource/Data  Contention 

In  this  experiment,  we  examine  the  performance  of  Star- 
Base  under  resource  and  data  contention.  The  deadline 
guarantee  ratio  is  shown  in  Figures  3  and  4  for  updating/ 
selecting  5  tuples  from  200,  600,  and  1000  tuple  size 
relation  tables.  In  Figures  3  and  4,  the  deadline  guaran¬ 
tee  ratio  drops  as  Pw  increases  and  the  size  of  the  table 
increases.  This  is  a  result  of  the  data  contention  that 
occurs  with  the  increase  of  Pw  or  the  table  size. 

Although  only  5  tuples  are  being  selected/updated,  in  a 
non-indexed  table  it  is  necessary  to  examine  all  the 
tuples  in  the  table  during  a  database  operation.  All  the 
tuples  in  the  read  set  are  then  marked,  and  the  opportu¬ 
nity  for  data  conflict  between  read/write  transactions  is 
greatly  increased  for  larger  relation  tables  as  write  trans- 
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actions  take  a  longer  amount  of  time  searching  for 
appropriate  tuples  to  update. 

5.2.  Experiment  2:  Transaction  Priority 

To  test  how  StarBase  handles  transaction  priorities,  we 
examine  how  StarBase  performs  when  given  mixed 
transaction  workloads.  In  each  of  these  workloads,  we 
vary  the  write  probability  Pw  again,  but  we  allow  the 
tuples  updated/selected  to  be  5,  25,  or  45  tuples.  Figure 
5  illustrates  the  deadline  guarantee  ratio  for  mixed  trans¬ 
action  workloads.  The  results  show  that  longer  transac¬ 
tions  (i.e.  those  transactions  that  update/select  more 
tuples)  have  a  lower  deadline  guarantee  ratio  than 
shorter  length  transactions.  As  the  execution  time 
increases,  the  possibility  of  data  conflict  increases  as 
well. 

Given  enough  short  transactions,  we  may  eventually  get 
a  “transaction  starvation”  [Hua91]  situation  where  long 
transactions  are  constantly  being  restarted  because  of 
conflicts  with  short  transactions.  The  starvation  problem 
can  be  avoided  by  assigning  long  transactions  a  higher 
priority.  The  results  of  running  the  same  workload  with 
the  new  priority  assignment  is  shown  in  Figure  6.  Under 
this  new  priority  assignment,  we  found  that  the  priority 
level,  not  the  length  of  transactions,  determines  the 
deadline  guarantee  ratio. 

5.3.  Experiment  3:  Indexing 

To  examine  the  performance  of  the  StarBase  T-Tree 
indexing  mechanism,  we  execute  the  same  workloads 
from  Experiment  1,  but  using  an  indexed  primary  key 
and  indexed  transaction  deadlines  for  the  three  different 
relation  table  size.  We  expect  to  see  the  deadline  guaran¬ 
tee  ratio  stay  level  as  Pw  increases  since  only  the  spe¬ 
cific  tuples  selected/updated  are  marked  in  the 
transaction’s  read  and  write  set.  The  drop  in  the  deadline 
guarantee  ratio  shown  in  Figures  7  and  8  can  be  attrib¬ 
uted  not  to  data  conflicts,  but  to  blocking.  In  the  Star- 
Base  T-Tree  implementation,  the  transaction  accessing 
tuples  from  the  T-Tree  must  lock  the  root  of  the  tree.  No 
other  transactions  can  access  the  T-Tree  at  this  time, 
regardless  of  the  operation  being  performed  on  the  tree. 
As  Pw  increases,  update  operations  which  lock  the  T- 
Tree  for  a  longer  period  will  decrease  the  overall  dead¬ 
line  guarantee  ratio  for  the  entire  transaction  set. 

We  have  attempted  to  enhance  the  performance  of  the  T- 
Tree  indexing  mechanism  by  altering  the  current  lock¬ 
ing  strategy.  As  long  as  the  T-Tree  is  not  altered,  then 
transactions  are  able  to  concurrently  access  the  T-Tree. 
For  a  write  operation,  which  alters  the  tree,  the  lock  is 
once  again  placed  on  the  root  of  the  tree.  The  perfor¬ 


mance  of  the  new  locking  strategy  is  compared  to  the 
former  one  in  Figure  9.  For  a  low  resource  contention 
level,  a  =  4,  the  new  locking  strategy  increases  the  num¬ 
ber  of  transactions  meeting  their  deadlines.  However, 
further  tests  show  that  as  the  resource  contention  level 
increases,  the  blocking  caused  by  the  write  operations 
overrides  any  performance  advantage  between  the  two 
locking  strategies. 

The  long  blocking  times  from  write  operations  also  con¬ 
flict  with  transaction  priority.  In  Experiment  2,  when  a 
mixed  priority  transaction  workload  was  submitted  to 
the  StarBase  server,  transactions  with  higher  priority 
showed  better  deadline  guarantee  ratios.  With  all  the 
transactions  now  competing  for  access  to  the  T-Tree, 
long  update  transactions  cause  many  more  shorter 
length  transactions  to  miss  their  deadlines.  Figure  10 
shows  the  performance  results  of  the  system  running  a 
mixed  transaction  workload  where  transactions  have  the 
same  priority  level.  As  a  result  of  the  long  blocking  time 
on  the  T-Tree  for  update  operations,  longer  length  trans¬ 
actions  actually  have  higher  deadline  guarantee  ratios 
than  short  transactions.  The  same  result  occurs  if  shorter 
length  transactions  are  given  higher  priorities  than  the 
longer  length  transactions. 

6.  Conclusions 

This  paper  presents  the  design  and  implementation  of  a 
firm  real-time  database  system  called  StarBase,  running 
on  a  real-time  operating  system  kernel,  RT-Mach.  We 
discuss  how  performance  was  evaluated  in  StarBase 
using  the  StarBase  workload  generator.  By  adjusting 
many  of  the  run-time  parameters  provided  by  the  work¬ 
load  generator,  we  have  examined  the  performance  of 
StarBase  under  different  environments  and  different 
transaction  workloads.  In  the  work  reported  in  this 
paper,  we  have  taken  an  in-depth  look  at  how  StarBase 
handles  resource  and  data  contention,  the  consideration 
of  transaction  priorities,  and  the  efficiency  of  the  T-Tree 
indexing  mechanism. 

From  the  resource  and  data  contention  experiments,  we 
can  see  that  in  an  environment  with  high  data  conten¬ 
tion,  an  indexing  mechanism  must  be  used.  Searching 
though  every  tuple  in  a  relation  is  clearly  unacceptable 
in  a  range  query,  leading  to  both  increased  response  time 
and  increased  data  conflict  rates.  An  improved  T-Tree 
indexing  scheme  for  StarBase  should  help  here. 

The  results  of  the  transaction  priority  tests  are  encourag¬ 
ing.  Even  without  the  proper  real-time  scheduling  policy 
in  place,  transactions  with  higher  priority  display  a 
higher  deadline  guarantee  ratio.  This  increase  occurs 
despite  the  fact  that  the  higher  priority  transactions  in 
the  workloads  are  longer  length  transactions  and  have 
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the  same  CPU  time  quantum  as  shorter-length  transac¬ 
tions.  Thus,  to  avoid  the  starvation  problem  mentioned 
in  Section  4,  longer-length  transactions  can  simply  be 
assigned  higher  priorities. 

Even  though  the  T-Tree  indexing  mechanism  did  not 
perform  as  well  as  expected,  we  believe  that  the  perfor¬ 
mance  can  still  be  improved  by  a  different  locking 
scheme.  The  locking  scheme  should  take  the  priority  of 
transactions  into  account,  and  unlike  the  previous  lock¬ 
ing  schemes,  it  should  allow  as  many  transactions  to 
access  the  T-Tree  as  possible.  Such  a  solution  will  not 
only  reduce  the  number  of  transactions  missing  their 
deadlines  due  to  T-Tree  blocking,  but  also  remove  the 
transaction  priority  problem  mentioned  in  Section  5.  We 
plan  to  implement  more  advanced  locking  schemes  in 
StarBase,  and  measure  the  performance  improvements. 

Future  work  should  address  how  StarBase  performs  in 
an  open  process  systems  environment.  Currently,  R.T- 
Mach  creates  periodic  threads  only  after  the  instantia¬ 
tion  of  the  previous  thread  has  completed.  This  problem 
has  prevented  any  experiments  on  how  StarBase  per¬ 
forms  under  different  transaction  arrival  rates.  We  also 
plan  to  correct  the  fixed-policy  round-robin  scheduling 
problem  so  that  we  can  obtain  a  truly  accurate  represen¬ 
tation  of  how  StarBase  performs  under  a  priority-driven 
scheduling  policy. 
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